|
|
On Friday 31 March 2006 10:19 am, Stephen Street wrote:
> On Fri, 2006-03-31 at 10:11 -0800, David Brownell wrote:
> > I don't know how your particular hardware works, but if you have a
> > real SPI controller it would probably be more natural to have your
> > setup() function handle that mode register earlier, out of the main
> > transfer loop ... unless that mode register is shared among all
> > chipselects, in which case you'd use the setup_transfer() call for
> > that, inside the transfer loop. (That call hasn't yet been merged
> > into the mainline kernel yet; it's in the MM tree.)
> >
> Is setup_transfer() a change to framework API or just the bit_bang
> driver?
Just bitbang.
> > The chipselect() call should only affect the chipselect signal and,
> > when you're activating a chip, its initial clock polarity. Though
> > if you're not using the latest from the MM tree, that's also your
> > hook for ensuring that the SPI mode is set up right.
>
> Ditto?
Ditto. Though it should also be OK, come to think of it, to keep
doing SPI mode selection in chipselect(); that shouldn't break.
- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at www.tux.org/lkml/">http://www.tux.org/lkml/
|
|